These should have the parameter name in the resulting string (see issue #3737).

Co-authored-by: Ralf Handl <[email protected]>

Co-authored-by: Ralf Handl <[email protected]>

Co-authored-by: Ralf Handl <[email protected]>

Co-authored-by: Ralf Handl <[email protected]>

Co-authored-by: Ralf Handl <[email protected]>

Limit interoperable parsing expectations (avoid type conflicts)

Be more clear about `format` support (3.1.1)

The "undefined" wording was chosen to allow implementations
that make a good-faith effort to accommodate non-string values
to remain compliant.  However, new implementations are not
expected to implement any sort of type coersion, and this
guides API designers away from that expectation.

The previous wording could be read to only restrict what sort
of request bodies could use an Encoding Object, while allowing that
it could be used with other entities that use a Media Type Object.

This emphasizes that it is only relevant to Request Body Objects,
and within that, only for specific media types.

The OAS does not define how to avoid collisions between parameter
values and style delimiters.  Mostly, this is straightforward,
but the need to URL encode space characters introduces extra
confusion.  Make it clear that managing this occurs outside
of the use of style, and is the responsibility of users.

JSON Schema draft 2020-12 includes numerous keywords that require
parsing the entire document prior to deeming a reference unresolvable.
This makes that more clear and outlines several approaches.

The practice of embedding OpenAPI fragments in other formats is
deemed to have implementation-defined (non-interoperable) behavior,
as the potential complications that might arise are not predictable.

Also, remove the example that goes against the advice in the
updated binary-handling section.

Clarify how to model binary data in 3.1

 Clarify `openIdConnectUrl` #3630

Correctly escape example operationRef URLs (3.1.1 port of #3731)

Non-string discriminator values (3.1.1 port of #3728)

Clarify spaceDelimited with spaces in values (3.1.1 port of #3723)

Clarify wording on encoding field (3.1.1 port of #3724)

If no Encoding Object is provided, the behavior is the same as
an empty Encoding Object, as none of its fields are required.

Also make the translation from 3.0 binary modeling a subsection,
as otherwise the line about streaming either feels randomly inserted
into the middle of the section, or feels disconnected when placed
after the conversion table.

fix style=form examples (3.1.1)

This goes into more detail and uses "undefined" instead of
"implementation-defined" as the behavior is likely to be
incorrect (rather than just a different interpretationof an
ambiguous requirement), and may result in security concerns
as well.

3.1.1: set release date

Add 3.0.4 release date to 3.1.1

3.1.1 set release date